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REMARKS 

General remarks. 

Claims 3-12 are all the claims pending in the application. Claims 1-2 have been canceled, 
and new claims 11 and 12 have been substituted. No new matter has been added. 

The claims have been extensively revised so as to overcome the rejection under 35 USC 
§ 112, and for improved clarity. 

Drawing objection. 

The Examiner indicated on the Office Action Summary that the drawings are objected to 
by the Examiner, but Applicant does not find in the Office Action any explanation for the 
objection. Applicant notes with interest the PT0948, but if the Examiner has any different 
objection to the drawings then the Examiner is respectfully requested to elaborate on the 
objection or to withdraw it. 

Claim objection. 

Applicant respectfully requests the Examiner to withdraw the objection to claim 10 in 
view of the self-explanatory changes shown above and in the enclosed appendix. 

The objection to the specification. 
The Examiner, apparently unfamiliar with the Internet Protocol Control Protocol, 
objected to the use of this term, and suggested that Applicant may have intended to use TCP/IP 
instead. Actually, the term used was the correct term, and applicant refers the Examiner to the 
following RFC which lays out the groundwork for the IPCP: RFC 1332. In view of the 
foregoing, applicant respectfully requests the Examiner to withdraw the objection to the 
specification. 
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Furthermore, applicant respectfully invites the Examiner to re-examine this application 
with the understanding that the specification and claims relate to IPCP (as indicated in the 
originally filed document) instead of TCP/IP. 

Applicant respectfully requests the Examiner to withdraw the objection to the part of the 
specification at page 5 in view of the correction of the informality shown above and in the 
enclosed appendix. 

The rejection under 35 USC § 112. 

The Examiner rejected claims 4-6 and 8-10 under 35 U.S.C. § 1 12, first paragraph, as 
containing subject matter which was not described in the specification in such a way as to enable 
one skilled in the art to which it pertains, or with which it is most nearly connected, to make 
and/or use the invention. 

More specifically, the Examiner objected to the part of the claims relating to the 

determination of whether a service level is satisfying or not. Applicant has revised the claims to 

avoid limitations that would lead the person of ordinary skill to think that the claim included a 

step of determining whether a given service level is satisfying or not. Instead, the claims (see, for 

example, claim 4) have language along the following lines: 

4. (Amended) The DTE according to claim 3, 
further comprising service level proposal 
renegotiating means, for generating 

another IPCP message requesting a service 
level, different from the proposed service 
level ... in response to an indication that 
said proposed service level is not a 
satisfying service level. 

The particular algorithm, for determining whether a service level is satisfying, is not the point of 
the invention defined by the claims now on file. Renegotiation of the service level in the event 
that the service level is not satisfying is the point of claims like claim 4. Therefore, the claim has 
been rewritten to say that the renegotiation occurs "in response to an indication that said 
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proposed service level is not a satisfying service level" without saying in the claims anything 
about how the state of satisfying or not satisfying is decided. 

Furthermore, applicant respectfully submits that it is certainly well within the skill of the 
person familiar with this field to come up with some kind of algorithm or way for determining 
whether a service level is satisfying or not. Since enablement relates only to that which is 
claimed, and since the claims have been appropriately rewritten (as described above), applicant 
respectfully requests the Examiner to withdraw this rejection. 

Also under section 112, paragraph 1, the Examiner rejected claims 5, 6, 9, and 10 for 
using the term "negotiating". In particular, the Examiner asserted that the term is not clear, and 
that the specification does not adequately define how the negotiating occurs. 

The claims, as now rewritten, avoid the potential problems mentioned by the Examiner. 

The method claims do not include a renegotiation step. The language of claim 9 is representative: 

a service level negotiating and proposing 
sub-module, ... for determining a service 
level that said DRE can provide ... . based on 
at least one predetermined criterion and on 
said requested service level, and 
formulating, as a service level proposal, an 
IPCP message indicating said determined 
service level; and 

Here, the sub-module is called a "negotiating and proposing sub-module" to give an idea of its 
function, but what the claim requires is "determining a service level" based on some criteria, and 
"formulating ... an EPCP message indicating said determined service level". The functions of the 
module are clear from the revised language of the claim, and these functions are clearly well 
supported in the specification as originally-filed. 

Applicant therefore respectfully requests the Examiner to withdraw this rejection in view 
of the claim amendments and the comments provided above. 
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The rejections over Hisanaga. 

The Examiner rejected claims 1-3, 5-7, and 9-10 under 35 U.S.C. § 102(a) as being 
unpatentable over Hisanaga et al, USP 5,907,556 (hereafter referred to as Hisanaga), and rejected 
claims 4 and 8 as being obvious over Hisanaga. Applicant now addresses both of these rejections 
together in the following discussion. 

What Hisanaga teaches. 

Hisanaga teaches a data transmission system in which a data sending unit 1 
communicates with a data receiving unit 2 over a transmission medium 4. Many sending units 
may communicate over the transmission medium 4 with the data receiving unit 2. The data 
receiving unit 2 has a built-in controller which controls the timing at which the data sending units 
1 may send data to the data receiving unit 2. 

The control unit 3 response to requests, from the sending units 1, for changes in allotted 
bandwidth and sets the bandwidth allotted to each sending unit 1 so as to avoid contention. The 
bandwidth controlled by control unit 3 is the bandwidth of the transmission medium 4 that is 
between the sending units 1 and the receiving unit 2. 

How the claims as now amended distinguish over Hisanaga. 

The invention defined by the claims, as now amended, is different. Applicant has 
amended the claims to make more clear the distinctions that are now described. 

In the present invention, a DTE sends data to a DRE for subsequent transmission over 
another network (referred to as a second network in the claims, this network could be the 
Internet, for example). The DRE is an edge node of the other network. 

The service level that the invention is concerned with is that of the sending of the data 
over the other network, and not necessarily the network that connects the DTE to the DRE. 

To make this distinction more explicit, applicant herein amends all of the independent 
claims as shown in the appendix. In particular, applicant points out that the claims as now 
amended include requirements explicitly indicating that the data from the DTE is being 
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communicated by the DRE over the second network, and that the service level pertains to that 
communication by the DRE of the data sent from the DTE for the second network. Furthermore, 
the claims require that various indications between the DTE and DRE, pertaining to the service 
level, are sent as IPCP messages. In particular, applicant draws the Examiner's attention to page 
2, beginning at line 10, in which is mentioned that the invention can be implemented by 
providing new options in the IPCP that forms part of the point-to-point protocol (PPP). 

In view of the amendments to the claims, applicant respectfully submits that the claims 3- 
11 patentably distinguish over Hisanaga. Hisanaga's teaching of a centrally controlled network 
cannot now be said to meet the above identified requirements of the independent claims, and 
would not have rendered unpatentable or anticipated the invention defined by these claims within 
the meaning of 35 USC §§ 102 or 103. 

The artisan of ordinary skill would not have (and could not have) been led by the 
teachings of Hisanaga to the invention now defined by any of the independent claims. 
Additional, untaught modifications would have been necessary. 

For all of the foregoing reasons, therefore, applicant respectfully requests the Examiner to 
withdraw this rejection of claims 3-10, and to withdraw the rejection as it may pertain to new 
claims 11 and 12 which are substituted for original claims 1 and 2. 

Conclusion and request for telephone interview. 

In view of the above, reconsideration and allowance of this application are now believed 
to be in order, and such actions are hereby solicited. If any points remain in issue which the 
Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly requested to contact the undersigned at the telephone number listed below. 
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The USPTO is directed and authorized to charge all required fees, except for the Issue 
Fee and the Publication Fee, to Deposit Account No. 19-4880. Please also credit any 
overpayments to said Deposit Account. 



Respectfully submitted, 



SUGHRUE MION, PLLC 
Telephone: (202) 293-7060 
Facsimile: (202) 293-7860 




WASHINGTON OFFICE 




23373 



PATENT TRADEMARK OFFICE 



Date: March 4, 2003 



13 



AMENDMENT UNDER 37 C.F.R. § 1.111 
APPLICATION NO. 09/384,422 
ATTORNEY DOCKET NO. Q55464 



APPENDIX 

VERSION WITH MARKINGS TO SHOW CHANGES MADE 
IN THE SPECIFICATION. 

Page 5, the paragraph beginning at line 10 and continuing through line 19. 

The service level request reception means SLR_Re_M has an input-terminal that is at the 
same time an input-terminal h of the data receiving element DRE and an output-terminal that is 
coupled to an input-terminal of the service level negotiating and proposing means SL_NP_M 
that in its turn is coupled with an output-terminal to an input-terminal of the service level request 
reception means SLR_Re_M. The service level proposal sending means SLP_S_M has an 
output-terminal that is at he the same time an output-terminal O3 of the data receiving element 
DRE. Then the data receiving means DRM contains an input-terminal that is at the same time an 
input-terminal I3 of the data receiving element DRE. 

IN THE CLAIMS : 

Please cancel claims 1 and 2, without prejudice or disclaimer, and substitute 
therefor new claims 11 and 12. 

3. (Amended) Data A data transmitting element (DTE)? to be used for sending data, over a 
link through a first communications network^ towards a data receiving element (DRE) for 
communication of said data over a second communications network , said data transmitting 
elem e nt DTE comprising the following means : 

— data sending means (DSM), adapted to send said data towards said data receiving el e ment 

DREt CHARACTERISED IN THAT SAID data transmitting element (DTE) further 

comprises the following m e ans y ± 
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service level requesting means (SL R M), adapted to requ e st for generating an Internet 
Protocol Control Protocol (IPCP) message, for sending to said data receiving element ( 
PRE^ )-#er requesting a service level for sending communicating said data of said DTE 
over said second communications network using an Intern e t Protocol Control Protocol 
message ; and 

— service level propose proposal receiving means (SLPRM), i coupled with 
an output to an input of said data sending means ( DSM \ and 

adapted to receive from said PRE an Internet Protocol Control Protocol propose for said 
IPCP message indicating a proposed service level that said PRE can provide for 
communicating said data of said DTE over said second communications network, and 
to notify 

notifying said data s e nding means ( DSM ) of said propose for said service level 
proposal . 

4. (Amended) The Data — transmitting — element — ( — DTE ) according to claim 3, 
CHARACTERISED IN THAT SAID data transmitting element (DTE), further comprises a 
comprising service level propose proposal renegotiating means (SLP_RNJM) , coupled between 
an output terminal of said service level propose proposal receiving means (SLP_RM) and an 
input terminal of said service level requesting meanSi (SLfl JVI) and adapt e d to ch e ck if for s akt 
Internet Protocol Control Protocol propose for said service level is satisfying and if not, to 
formulate generating another r e quest for said IPCP message requesting a service level different 
from the proposed service level indicated in said IPCP message from said PRE, in response to an 
indication that said proposed service level is not a satisfying service level . 

5. (Amended) Data A data receiving element (PRE), to be used for receiving data from a 
data transmitting element (PTE) , over a link through a first communications networ k, and 
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communicating said data over a second communications network from a data transmitting 
element (DTE) , said data receiving element ( DRE ) comprising th e following means : 

— data receiving means (DRM), adapted to receive said data from said data transmitting 

element, CHARACTERISED IN THAT SAID data receiving element (DRE) further 

comprises th e following means: DTE; 

service level request reception means (SLR_Re_M), adapted to r e ceive for receiving an 
Internet Protocol Control Protocol (IPCP) message, from said DTE, indicating a requested 
service level request from said data transmitting element ( for said communicating of said 
data of said DTE ) using an Internet Protocol Control Protocol message over said second 
communications network ; 
— service level negotiating and proposing means (SL_NP_M) , coupled with an input to an 
output of said service level request reception means (SLR_Re_M) and adapted to 
determine , for determining a service level that said DRE can provide for communicating 
said data of said DTE with said second communications network, based on at least one 
predetermined criterion and on said requested service level, and to formulate a propose for 
formulating, as a service level proposal, an IPCP message indicating said determined 
service level; and 

dr— service level proposal sending means (SLP_SM) , coupled with an input to an output of said 
service level negotiating and proposing means , for (SLNP M) and adapted to send sending 
said propose for said servic e level using an Internet Protocol Control Protocol message 
IPCP message as said service level proposal . 

6. (Amended) Data A data receiving element (DRE), to be used for receiving data from a 
data transmitting element (DTE) , over a link through a first communications networ k, and 
communicating said data over a second communications network from a data transmitting 
element (DTE) , said data receiving element ( DRE ) comprising the following means : 
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a-. — data receiving means (DRM), adapted to receive said data from said data transmitting 
element, CHARACTERISED IN THAT SAID data receiving element (DRE) furth e r 
comprises th e following m e ans: DTE; 

k— service level negotiating and proposing means (SLNPM) , adapted to determine , for 
determining a service level that said DRE can provide for communicating said data of said 
DTE with said second communications network, based on at least one predetermined 
criterion and on said requested service level, and to formulate a propose for formulating, as 
a service level proposal, an IPCP message indicating said determined service level; and 

er— service level proposal sending means (SLP_SM) , coupled with an input to an output of said 
service level negotiating and proposing means , for (SLNP M) and adapted to send sending 
said propose for said service level using an Internet Protocol Control Protocol message 
IPCP message as said service level proposal . 

7. (Amended) Software A software module for running on a processing system for inclusion 
in a data transmitting element (DTE), for sending data, over a link through a first 
communications network^ towards a data receiving element (DRE) for communication of said 
data over a second communications network , said software module comprising the following 
sub modules : 

a^-a data sending sub-module, adapted to send said data towards said data r e ceiving element 
DREt CHARACTERISED IN THAT SAID software modulo further comprises the 
following sub modules:; 

a service level requesting sub-module, adapted to request for generating an Internet 
Protocol Control Protocol (IPCP) message, for sending to said data r e ceiving element ( 
DRE a )-4ef requesting a service level for sending communicating said data of said DTE 
over said second communications network using an Internet Protocol Control Protocol 
messag e; and 

— a service level propose proposal receiving sub-module T : 
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adapted to receive from said DRE an Internet Protocol Control Protocol propose for said 
IPCP message indicating a proposed service level that said DRE can provide for 
communicating said data of said DTE over said second communications network, and 
to notify 

notifying said data sending sub-module of said propose for said service level proposal . 

8. Software The software module according to claim 7, CHARACTERISED IN THAT 
SAID software module, further comprises comprising a service level propose proposal 
renegotiating sub-module, co-operating with said service level propose proposal receiving sub- 
module and said service level requesting sub-module,, and adapt e d to check if for said Internet 
Protocol Control Protocol propose for said service level is satisfying and if not, to formulat e 
generating another request for said IPCP message requesting a service level, different from the 
proposed service level indicated in said IPCP message from said DRE, in response to an 
indication that said proposed service level is not a satisfying service level . 

9. (Amended) Software A software module for running on a processing system for inclusion 
in a data receiving element (DRE), for receiving data from a data transmitting element (DTE) , 
over a link through a first communications network , and communicating said data over a second 
communications network from a data transmitting elem e nt (DTE) , said software module 
comprising the following sub modules : 

ar— a_data receiving sub-module, adapted to receive said data from said data transmitting 
element (DTE), CHARACTERISED IN THAT SAID software modulo further compris e s 
the following sub modules: DTE; 

b^-a_service level request reception sub-module, adapted to r e ceive for receiving an Internet 
Protocol Control Protocol (IPCP) message, from said DTE, indicating a requested service 
level request from said data transmitting element ( for said communicating of said data of 
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said DTE ) using an Internet Protocol Control Protocol message over said second 
communications network ; 

e^— a_service level negotiating and proposing sub-module, co-operating with said service level 
request reception sub-module and adapt e d to determine , for determining a service level 
that said PRE can provide for communicating said data of said DTE with said second 
communications network, based on at least one predetermined criterion and on said 
requested service level, and to formulate a propose for formulating, as a service level 
proposal, an EPCP message indicating said determined service level; and 

dr— a service level proposal sending sub-module, co-operating with said service level 
negotiating and proposing sub-module , for (SLNP_M) and adapt e d to send sending said 
propose for said service level using an Internet Protocol Control Protocol messag e IPCP 
message as said service level proposal . 

10. (Amended) Software A software module for running on a processing system for inclusion 
in a data receiving element (DRE), for receiving data from a data transmitting element (DTE) , 
over a link through a first communications networ k, and communicating said data over a second 
communications network from a data transmitting elem e nt (DTE) , said software module 
comprising the following sub modul e s : 
a-. — a data receiving sub-module, adapted to receive said data from said data transmitting 
element (DTE), CHARACTERISED IN THAT SAID software modulo further compris e s 
the following means: DTE; 
dr— a service level negotiating and proposing sub-module, adapted to determine for 
determining a service level that said DRE can provide for communicating said data of said 
DTE with said second communications network, based on at least one predetermined 
criterion and on said requested service level, and to formulate a propose for formulating, as 
a service level proposal, an IPCP message indicating said determined service level; and 
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— a service level proposal sending sub-module, co-operating with said service level 
negotiating and proposing sub-module and adapted to sen d , for sending said propose for 
said servic e l e vel using an Internet Protocol Control Protocol messag e IPCP message as 
said service level proposal . 
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